Presently available on-line quoting tools for insurance products, such as auto insurance, do not allow a user to receive real-time advice. The current environment consists, for example, of Hypertext Markup Language (HTML) forms that allow a user to enter some of the information needed for the generation of auto quotes. That information is then emailed to a customer support representative (CSR) via a Common Gateway Interface (CGI) process. The CSR subsequently contacts the user to gather additional information and generate a quote, for example, via a legacy system. Thus, it is not possible for the user to receive real-time advice, such as the availability of different types of insurance products or the various coverage requirements of different states.
Building data processing systems is much like building a house. Viewed from that perspective, a technical architecture or infrastructure of a software system represents the blueprints, foundation, plumbing, insulation, and electrical components of a home. When a homeowner purchases a new home, he/she may choose to build upon its foundation and structure. Customizations like floorings, siding windows and fixtures will tailor the house to meet the homeowner's specific needs, while preserving its structural integrity. Similarly, each application or project using the technical infrastructure will need to define an “applications architecture” that will leverage the architecture to address its specific needs. Furthermore, the tools provided with the technical infrastructure must allow individual applications flexibility in design, while ensuring the applications' operational integrity and maintainability.
FIG. 37 shows a known technical infrastructure of a data processing system, which is server-based in its design and includes Windows NT-based client desktops 1010 (e.g., personal computers), servers 1020, and mainframe hosts 1-70 in a systems environment. Most client users have little beyond the operating system (OS) installed on their desktops. As for the servers, these machines are typically configured as file servers and contain space for users' home directories and personal system configurations (e.g., INI files), as well as shared drives for organizational use. All applications and most office automation software are typically stored on host file servers, i.e., at the server level, and downloaded to the desktop when needed. Each server is configured as an NT backup domain controller and implemented with Windows NT security authentication. Thus, users must provide a login and password to gain access to the software system. Furthermore, a single NT primary domain controller is typically installed in a central node location 1030. The known data processing system may also include a server 1050 that is based on OS/2 and configured for support and optimal execution of DOS applications written in Basic computer language. Most host mainframe applications are MVS/IMS-based (Multiple Virtual Storage/Information Management System), although some run under MVS/CICS (Customer Information Control System). These applications are currently accessed via 3270 emulation using Attachmate Extra! software, which is installed on the server 1020 as shown in FIG. 37.
The known system environment typically uses IMS/DB (DataBase) and DB2 database management systems on the host mainframe and Microsoft SQL (Structured Query Language) server at the host server level as database managers. Some applications also make use of Microsoft Access. Some Access databases can be installed in the field while other application databases reside on servers in the central node location 1030 or on the host mainframe 1070. Office automation and other databases are handled in different ways, depending on their structure and usage. For instance, Folio databases, which are read-only in nature, are deployed to the field on Windows NT servers, such as server 1020. Lotus Notes databases, which may be read-only or read/write, are installed in the central node location 1030.
For communication protocols, most LAN/WAN traffic to the central node location for desktop-to-server communication is conventionally based on IBM's NetBIOS protocol, with some systems implementing Novell's IPX protocol. Whereas, SNA and 3270 Bisynch are used for communication between desktops and host mainframes. Several techniques are commonly used for server-to-mainframe communications. The tools and protocols used include IBM DDCS for communication with DB2, DTF to MVS/CICS, LU2 to MVS/IMS, IBM's MQ Series software, and Texas Instruments (TI) Communication Bridge. For groupware, the host software system environment uses Lotus Notes to support e-mail, workflow, and (on a limited basis) document management activities, with the Notes servers all installed in the central node location. Software distribution to Windows NT clients and servers is performed using Microsoft's SMS tools. Distribution between OS/2 servers is done using Ascom Timeplex's Synchrony products. The known application development tools of choice are Microsoft Visual Basic (VB) for local applications and TI Composer for accessing host data sources. Most legacy applications are written in IMS COBOL. The known client/server applications are written such that work-in-process, or work-in-progress, (WIP) data is created and manipulated at the server level, and forwarded to the mainframe for permanent storage upon completion of a unit of work.
The aforementioned known system environment suffers from several shortcomings that inhibit its effectiveness in the current business environment. First, this environment suffers from inconsistent application “look and feel” because it contains a mix of mainframe and client/server systems. From a user presentation perspective, character-based mainframe applications operate in a fundamentally different manner from those server applications that were developed employing a graphical user interface (GUI). Even applications written for the same platform (i.e., for the same mainframe or server) do not employ a consistent mode of operation; thus, inhibiting user productivity. Second, there is a lack of interoperability. The applications of the known environment were, for the most part, independently developed from one another and do not share common data. Numerous situations exist where, in order for the user to carry out a business transaction, data must be re-keyed into multiple applications that behave inconsistently.
This is not only undesirable from a productivity perspective, but may cause data synchronization problems in cases where information is incorrectly entered. Third, there is a lack of reuse. In other words, a problem caused by the lack of synergy between the current applications is that code that should be common to all applications is often reinvented. For example, slightly different code for validating office codes of an insurance agent as a system user may exist in many system applications, where a single, standard approach to performing this function would be sufficient. Fourth, as noted above, the known client/server applications are typically written such that data is created and manipulated at the server level, and forwarded to the mainframe for permanent storage upon completion of a unit of work. This technique of remote data access consumes considerable network bandwidth, and ideally should be discarded in favor of an infrastructure strategy that allows data to be manipulated closer to its source.